Is there a good reason why these should be separate?

The --install line creates the required kernel.json spec file for Jupyter and installs it in the right location by invoking jupyter kernelspec install.

I saw the pattern used by other kernels distributed on PyPI, does pip have a concept of a post-install script that could do the same thing?

I had Claude investigate, here's what it found. I think the caveat is important enough that we just stick with the current approach?

"pip doesn't have a post-install hook for wheels — modern pip just extracts the wheel directly with no custom code execution (by design, PEP 427). And since this is a maturin bindings = "bin" project with no Python code at all, there's nothing to hook into anyway.

However, there is a clean alternative: maturin supports a .data directory mechanism that can auto-place a kernel.json into the Jupyter kernelspec directory at install time, with no second step required. You'd create:

ggsql-jupyter/
  ggsql_jupyter.data/
    data/
      share/
        jupyter/
          kernels/
            ggsql/
              kernel.json

The data/ subdirectory maps to sys.prefix on install, and Jupyter searches {sys.prefix}/share/jupyter/kernels/ by default. So pip install ggsql-jupyter would automatically register the kernel. The kernel.json argv would just reference ggsql-jupyter by name (since pip puts the binary on PATH in the venv).

Main caveat: this works well for virtualenv/conda installs (the common case), but for pip install --user, sys.prefix points to the system prefix rather than ~/.local, so the kernelspec placement may not be ideal. The --install flag would still be useful as a fallback for non-pip installs (cargo install, binary downloads) and for explicit --user/--sys-prefix targeting."

Thanks, that's useful.

Hmmm, it sounds like it would work most of the time but then be annoying when it doesn't. Yes, let's stick with this method for now, the --install argument is useful for replacing the kernel in local development too.